マネージドルールCommonRuleSetによるブロックと例外登録を行う

WS WAFですが、2019/11/25のアップデートで「New AWS WAF（WAF v2）」が登場しました。WAF v2ではAWSが提供するマネージドルールを利用できます。今回はマネージドルール「AWS-AWSManagedRulesCommonRuleSet」での検知と、例外登録について、ご紹介します。

#AWS WAF

#AWS

阿部洸樹

2019.12.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS WAFですが、2019/11/25のアップデートで「New AWS WAF（WAF v2）」が登場しました。WAF v2ではAWSが提供するマネージドルールを利用できます。今回はマネージドルール「AWS-AWSManagedRulesCommonRuleSet」での検知と、例外登録について、ご紹介します。

Web ACLの作成

新しいWAFコンソールから、Create web ACLを選びます。Web ACLの名前を入力し、Web ACLを割り当てるリソースを選択します。今回はALBに割り当てます。

マネージドルールを追加します。

執筆時点で、AWSが提供するルールだけで10個ありますが、今回はCore rule setを選びます。「Add to web ACL」を選択します。最初からブロックで導入するため、「Set rules action to count」はオフにします。

「AWS-AWSManagedRulesCommonRuleSet」に一致するとブロック。一致しない場合はDefault actionで許可されます。「AWS-AWSManagedRulesCommonRuleSet」は700WCUs（Web ACL Capacity Unit）を使用します。1つのWeb ACLでは1500WCUsまで利用できるため、残り、800WCUsまでルールを追加できます。AWS WAF Classicでは、ルール数による制限でしたので、変更点になりますね。

ルールの評価順を設定します。ルールは表示順に実行されます。1つのルールのみなので、今回は関係ないですね。

メトリクス名を設定します。デフォルトでルール名と同じ名前が設定されます。デフォルト値にしました。

ここまででWeb ACLが作成されました。

ログの有効化

AWS WAFのログはKinesis Data Firehose経由でS3に出力します。設定はAWS WAF Classicと変わらないようです。

Kinesis Firehoseの作成

KinesisコンソールからData Firehoseを選び、「Create delivery stream」を選択します。「aws-waf-logs-」からはじまる名前でデリバリストリームを作成します。今回は、aws-waf-logs-wafv2としました。その他の設定はそのままにします。

Process recordsもデフォルトのまま進みます。

宛先はS3にします。

Configure settingsはIAMロール以外はデフォルトのままにします。

IAMロールについては、「Create new or choose」を選ぶと作成されます。

確認画面が表示されるので、作成します。

ログの有効化

Web ACLの名前を選択し、Logging and metricsからログを有効化します。

先ほど作成したKinesis Data Firehoseを選びます。ログに表示させないフィールドを選べますが、今回は選択しませんでした。

マネージドルールの確認

Rulesを選び、Editします。

マネージドルール内のルール名とそのアクションを選べます。「NoUserAgent_HEADER」というルールなどがあります。AWS WAF Classicでは、このあたりを確認できませんでした。良いアップデートだと思います。

ユーザーエージェントをセットしない通信の送信

「NoUserAgent_HEADER」というルールがあるので、試しにcurlコマンドでユーザーエージェントを空にしたところ、WAFでブロックされました。

$ curl -H 'User-Agent:' http://elb-dnsname
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
</body>
</html>
$

Overviewから過去3時間のサンプルリクエストを確認できます。二件の通信がブロックされていることがわかります。マッチルールから、CommonRuleSetのNoUserAgent_HEADERでブロックされたことがわかりますね。

URIを選択すると、Request bodyを確認できます。

NoUserAgent_HEADERを許可する

マネージドルールのEdit画面から、「NoUserAgent_HEADER」のOverride rules actionを有効にします。

再度アクセスすると、許可されます。

$ curl -H 'User-Agent:' http://elb-dnsname
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<h1>Hello World !!</h1>
</body>
</html>
$

ブログを書いている間にも攻撃がきた

余談ですが、ブログを書いている間にも攻撃がきたのでシェアします。本ブログを書くためにALBを3時間程度起動していましたが、XSS攻撃が来ていました。検知したルールは「CrossSiteScripting_BODY」です。ALBを利用する場合は、できる限りセキュリティグループで必要なIPアドレスだけを許可すると良いでしょう。